Software Requirements Analysis & Specification

1. What is Requirement Engineering?

Requirement engineering is the process of collecting, analyzing, and writing down what a software should do. It helps software developers understand exactly what the user wants.

Main Steps in Requirement Engineering:

• Feasibility Study: Check if the project is possible and worth doing.
• Requirement Elicitation: Talk to users to know what they need.
• Requirement Analysis: Study and organize the collected requirements.
• Requirement Specification: Write the requirements clearly.
• Requirement Validation: Make sure requirements are correct and complete.
• Requirement Management: Handle any changes in requirements over time.

2. Techniques to Collect Requirements (Requirement Elicitation)

2.1 FAST (Facilitated Application Specification Technique)

FAST is a method where users and developers sit together in a meeting and talk about what the system should do. They prepare and agree on the requirements together.

2.2 QFD (Quality Function Deployment)

QFD helps in converting what customers want into technical things that developers can work on. It gives importance to product quality from the very beginning.

• First, understand what the customer needs.
• Then, define how the software can meet those needs.
• Finally, prepare a matrix (table) to connect customer needs with software features.

3. Requirement Analysis

In this step, we take all the collected requirements and make models to understand the system better. These models help in planning and designing the software.

3.1 DFD (Data Flow Diagram)

This shows how data moves in the system. It shows input, processes, and output.

      [User] → (Login Process) → [Check Credentials] → [Dashboard]
      

3.2 Use Case Diagram

It shows what users (actors) can do with the system. Each action is called a "use case".

      Actor (Customer) → Use Case (Place Order)
      

3.3 Sequence Diagram

This diagram shows the order in which different parts of the system talk to each other during a process.

      Customer → Order Page → Payment Gateway → Order Confirmation
      

3.4 Class Diagram

This shows the different parts (classes) of the system, and what they do.

      Class: Customer
      + name
      + email
      + register()
      + login()
      

3.5 ER Diagram (Entity Relationship Diagram)

This is used to design the database. It shows different entities (like Customer, Product) and how they are related.

      Customer --places--> Order
      Order --contains--> Product
      

4. Requirements Documentation: SRS

SRS (Software Requirements Specification) is a document that explains what the software will do. It is used by developers to understand and build the software.

4.1 Good Features of an SRS

• Correct: All details should be right.
• Clear: Easy to understand without confusion.
• Complete: Nothing important should be missing.
• Consistent: No conflicts in the document.
• Verifiable: Every requirement should be testable.
• Modifiable: Easy to change when needed.
• Traceable: Every point should link back to its source (who asked for it).

4.2 How an SRS is Organized

1. Introduction: What the system is and why it's being made.
2. Overall Description: General features and users.
3. Specific Requirements: What the software must do exactly.
4. External Interface Requirements: How the system will interact with hardware or other software.
5. Non-Functional Requirements: Like speed, security, etc.
6. Appendices: Extra information if needed.
7. Index: Table for easy search.